Painel de líderes

RESOLVIDO Na escrita da string eu adicionei um "\n" no fim de cada parâmetro para ele chegar formatado no ACBR, aparentemente o problema era que o comando chegava em uma única linha

Olá pessoal, Com o intuito de acabar com a dependência da CAPICOM, nos fontes do Projeto ACBr, apliquei um amplo refactoring, nas Units de ACBrDFeSSL e suas derivadas... O que é CAPICOM ? https://en.wikipedia.org/wiki/CAPICOM Porque usávamos a CAPICOM ? Usar diretamente as APIs do Windows não é uma tarefa simples.... A CAPICOM, facilita um pouco, as tarefas que podem ser feitas com a WinCrypt (ou MS Crypto), para acesso a certificados digitais instalados no Windows Quais as desvantagens da CAPICOM ? A Microsoft condenou a mesma como obsoleta. (esse é o principal motivo) Ela precisa ser registrada no Windows para funcionar Não suporta 64 bits O que será usado no lugar da CAPICOM ? Usaremos diretamente as APIs do Windows, ou seja, a WinCrypt (também conhecida como "MS Crypto" ou "CAPI"). Ou seja, encaramos o desafio e agora usamos apenas métodos da WinCrypt para acessos a Certificados Digitais no Windows. Para facilitar o acesso a API WinCrypt, estamos usando as Units do diretório: "Fontes\Terceiros\CodeGear\", mas especificamente a Unit "ACBr_WinCrypt.pas". Quais as vantagens da WinCrypt ? Ela está presente de forma nativa, em todas as versões do Windows (desde o Windows XP), ou seja, não requer instalação. Possui versões 32 e 64 bits Não requer registro da DLL Não requer a instalação de pacotes .NET ou Java Onde posso encontrar a WinCrypt ? Ela já está instalada, de forma nativa, no seu Windows... com o nome: "crypt32.dll" Se o seu Windows é 64 bits, você encontrará a mesma em: 32 bits: "C:\Windows\SysWOW64" 64 bits "C:\Windows\System32" Se o seu Windows é 32 bits, você encontrará a mesma em: "C:\Windows\System32" O suporte a Delphi7 será mantido ? SIM. Apesar de já anunciarmos o fim do Suporte a D7, tivemos o cuidado de testar as alterações no D7. Para isso, adaptamos as units da pasta "Fontes\Terceiros\CodeGear\" para o suporte a D7... Como configurar para usar a WinCrypt e não a CAPICOM ? A maneira mais simples é configurar a seguinte propriedade: ACBrNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; Na verdade, a propriedade ACBrDFe.Configuracoes.Geral.SSLLib passou a ser virtual... ou seja, ela configurará de forma indireta, as 3 novas bibliotecas de TDFeSSL... Se você ler os fontes, quando rodamos o código acima, o seguinte código será executado. procedure TGeralConf.SetSSLLib(AValue: TSSLLib); case AValue of ..... libWinCrypt: begin SSLCryptLib := cryWinCrypt; SSLHttpLib := httpWinHttp; SSLXmlSignLib := xsMsXml; end; end; Se você deseja uma configuração diferenciada, poderá configurar as bibliotecas individualmente...Exemplo: ACBrNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBrNFe1.Configuracoes.Geral.SSLHttpLib := httpWinINet; ACBrNFe1.Configuracoes.Geral.SSLXmlSignLib := xsXmlSec; Como remover completamente, as Units da CAPICOM dos meus fontes ? Abra o arquivo \ACBr\Fontes\ACBrComum\ACBr.inc e altere a seguinte linha: {.$DEFINE DFE_SEM_CAPICOM} para: {$DEFINE DFE_SEM_CAPICOM} Ou seja, remova o "." do inicio O que mudou em ACBrDFeSSL ? Muita coisa.... (veja abaixo o trecho do "Change-Log").. Estudar os fontes do projeto Demo "\ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi", é a melhor maneira de conhecer as modificações. Veja abaixo, um resumo ilustrado: 1 - Agora você pode criar a sua própria janela de escolha de Certificado Veja esse exemplo de código, extraído de ACBrNFe_Demo. onde usamos o método "ACBrNFe1.SSL.LerCertificadosStore", para carregar todos os certificados da Store, definida em "ACBrNFe1.SSL.StoreName", após isso, as informações dos certificados podem ser obtidas em "ACBrNFe1.SSL.ListaCertificados" ACBrNFe1.SSL.LerCertificadosStore; For I := 0 to ACBrNFe1.SSL.ListaCertificados.Count-1 do begin with ACBrNFe1.SSL.ListaCertificados[I] do begin 2 - Agora você pode selecionar as bibliotecas de TDFeSSL, individualmente CryptLib: Permite definir qual será a biblioteca de Criptografia. Ela possui métodos como:"SelecionarCertificado", "CarregarCertificado", "CalcHash". além de propriedades como "DadosCertificado" e "ListaCertificados". TSSLCryptLib = (cryNone, cryOpenSSL, cryCapicom, cryWinCrypt) HttpLib: Usada para acesso HTTP e HTTPs, permitindo informar o Certificado na conexão. Possui métodos como: "Enviar" e propriedades como: "HTTPResultCode" e "InternalErrorCode" TSSLHttpLib = (httpNone, httpWinINet, httpWinHttp, httpOpenSSL, httpIndy); XMLSignLib: Usada para validar XMLs (contra um Schema), assinar um XML, Validar a assinatura existente em um XML. Possui métodos como: "Assinar", "Validar" e "VerificarAssinatura" TSSLXmlSignLib = (xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom); 3 - Independência das configurações de segurança do I.E. Isso pode ser obtido, se você utilizar SSLHttpLib = "httpWinHttp" ou "httpOpenSSL" Você poderá definir nos seus fontes, independente das configurações do Internet Explorer, configurações como o Tipo de segurança e TimeOut da tentativa de conexão. Essa funcionalidade já estava presente nas Units de acesso que utilizavam o OpenSSL a algum tempo. e agora com a nova Unit que faz acesso a HTTPS, usando a API do Windows chamada "WinHTTP", isso também será possível. O modelo: "httpWinINet" irá usar a API do Windows, chamada "WinINet", a qual já utilizávamos, e ela depende de configurações do I.E. 4 - Carregar o certificado por ArquivoPFX ou DadosPFX, com a WinCrypt ou CAPICOM Essa funcionalidade já estava presente, quando SSLCryptLib = cryOpenSSL. e não estava disponível para CAPICOM. Mas agora isso é possível, com a SSLCryptLib = cryCapicom ou cryWinCrypt. Ou seja, Se você tem um certificado A1, você não precisa instalar o certificado no Windows. Isso pode parecer pouco importante em uma primeira impressão... Mas veja as possibilidades: O certificado A1 poderia estar em um Banco de dados, ou em um Servidor Web, e ser carregado de forma dinâmica pela sua aplicação, independente de ser instalado manualmente no Windows. 5 - Compilar seu Executável em 64 bits Lembre-se que quando você compila o seu programa em 64 bits, todas as DLLs externas de qual ele necessitar, também devem ser de 64 bits. Portanto para isso, você não poderá usar a XMLSignLib = xsMsXml, pois a biblioteca da Microsoft para assinatura de XMLs "MSXML" não possui versão 64 bits. Mas observe que agora você pode usar a biblioteca WinCrypt com a XmlSec, basta configurar corretamente as bibliotecas de criptografia. Nota: Ainda não conseguimos, fazer com que a XMLSec possa usar certificados A3, mas isso deverá ser possível no futuro, pois a XMLSec tem suporte a "MSCrypto" Diagrama de Classes Como posso ajudar ? (Tarefas a serem efetuadas) 1 - Fazer a XmlSec funcionar usando a "mscrypto" Ainda não conseguimos fazer a XMLSec, usar a MSCrypto, atualmente ele apenas usa a "openssl". Porque isso é importante ? Temos vários problemas, com a msxml, como por exemplo: A Microsoft não distribui a mesma, de forma nativa, com o Windows (arquivo msxml5.dll) Ela não suporta 64 bits A licença de uso dassa biblioteca, é valida apenas para quem tem o Office instalado... Portanto, seria ótimo se pudéssemos ficar livres da MSXML, mas para isso, precisamos fazer o ACBr conseguir usar a XMLSec com suporte a MSCrypto (hoje ele só suporta OpenSSL)... Na verdade, já podemos usar WinCrypt + XmlSec, mas apenas para certificados A1, pois o ACBr é capaz de exportar o certificado A1 do Windows, para que o mesmo seja usado pelo OpenSSL. (ele fará isso internamente, e de forma transparente para o usuário) Quando conseguirmos fazer a XmlSec usar a MSCrypto (ou WinCrypt), conseguiremos compilar a aplicação em 64 bits, e com suporte a certificados A3 2 - Compilar os fontes da XMLSec no Windows, em 32 e 64 bits Hoje o único site que distribui a XMLSec já compilada para Windows é https://www.zlatkovic.com/libxml.en.html (Thanks Igor). Entretanto, podemos notar que os binários estão defasados, e não há uma versão 64 bits, com suporte a "mscrypto" Veja como ficou o "Change-Log" do refactoring em ACBrDFeSSL -- ACBrDFeSSL -- [*] Amplo refactoring promovido, separando a classe "TDFeSSLClass" em 3 novas classes: "TDFeSSLCryptClass" - para Carregar certificados e efetuar criptografia "TDFeSSLHttpClass" - para comunicação HTTP/HTTPS com suporte a Certificados "TDFeSSLXmlSignClass" - Para Validar XMLs, validar assinaturas e Assinar XML com Certificados [+] "TSSLLib", adicionado os tipos "libWinCrypt, libCustom" [+] Criada nova classe "TDadosCertificado", para conter os dados do certificado carregado [+] Criada nova classe "TListaCertificados",para conter uma lista de Objetos do tipo TDadosCertificado, com todos os certificados de uma "Store", e após a chamada do método "TDFeSSL.LerCertificadosStore" [+] Adicionada propriedade "TDFeSSL.StoreName: String", usada apenas no Windows. Nome da Store a ser aberta, padrão "MY" [+] Adicionada propriedade "TDFeSSL.StoreLocation: TSSLStoreLocation", usada apenas no Windows. Default "slCurrentUser". TSSLStoreLocation = (slMemory, slLocalMachine, slCurrentUser, slActiveDirectory, slSmartCard); [+] Adicionado o método: "TDFeSSL.LerCertificadosStore", apenas Windows, para carregar todos os Certifcados de "TDFeSSL.StoreName" para a lista de Objetos: "TDFeSSL.ListaCertificados" [+] Adicionado a propriedade "TDFeSSL.DadosCertificado", para permitir acesso aos dados do certificado carregado [+] Adicionada a propriedade "TDFeSSL.SSLCryptLib: TSSLCryptLib" default cryNone; para definir a classe de criptografia TSSLCryptLib = (cryNone, cryOpenSSL, cryCapicom, cryWinCrypt); [+] Adicionada a propriedade "TDFeSSL.SSLHttpLib: TSSLHttpLib" default httpNone; para definir a classe de comunicação HTTP/HTTPS TSSLHttpLib = (httpNone, httpWinINet, httpWinHttp, httpOpenSSL, httpIndy); [+] Adicionada a propriedade "TDFeSSL.SSLXmlSignLib: TSSLXmlSignLib" default xsNone; para definir a classe de assinatura de validação de XML TSSLXmlSignLib = (xsNone, xsXmlSec, xsMsXml, xsMsXmlCapicom); [+] Adicionada a propriedades "TDFeSSL"SSLType: TSSLType" default LT_all; para permitir definir o tipo de criptografia em HTTPS sendo: TSSLType = (LT_all, LT_SSLv2, LT_SSLv3, LT_TLSv1, LT_TLSv1_1, LT_TLSv1_2, LT_SSHv2) suportado apenas em TDFeHttpOpenSSL e TDFeHttpWinHttp -- ACBrDFeConfiguracoes -- [+] Adicionada as propriedades: property SSLCryptLib: TSSLCryptLib property SSLHttpLib: TSSLHttpLib property SSLXmlSignLib: TSSLXmlSignLib [*] Propriedade "SSLLib: TSSLLib" passou a ser virtual, e mantida por compatibilidade. Ajusta-la irá produzir ajustes em "SSLCryptLib", "SSLHttpLib" e "SSLXmlSignLib". Exemplo: if SSLLib = libOpenSSL then begin SSLCryptLib := cryOpenSSL; SSLHttpLib := httpOpenSSL; SSLXmlSignLib := xsXmlSec; end; -- ACBrDFe -- [+] Adicionado suporte a configurações de "SSLCryptLib", "SSLHttpLib", "SSLXmlSignLib" -- ACBrDFeOpenSSL -- [*] Amplo refactoring. Removido código referente a comunicação HTTP/HTTPs que foi migrado para "ACBrDFeHttpOpenSSL" [*] Removido código referente a assinatura digital e Validação de XML, que foi migrado para "ACBrDFeXsXmlSec" -- ACBRDFeWinCrypt -- [+] Nova Unit, para manipular Certificados do Windows e efetuar assinatura digital, usando a Win API WinCrypt (MSCrypto/CAPI) -- ACBrDFeCapicom -- [*] Refactoring, para usar boa parte do código de "ACBRDFeWinCrypt" -- ACBrDFeHttpOpenSSL -- [+] Adicionada nova Unit, derivada de ACBrDFeOpenSSL, criando implementação da classe de TDFeSSLHttpClass para comunicação http e https, usando a Synapse e OpenSSL -- ACBrDFeHttpWinApi -- [+] Adicionada nova Unit, derivada de ACBrDFeCapicom, criando implementação da classe de TDFeSSLHttpClass para comunicação http e https, usando as APIs do Windows WinHttp ou WinINet -- ACBrDFeHttpIndy, ACBrDFeCapicomDelphiSoap -- [*] Unit renomeada de "ACBrDFeCapicomDelphiSoap" para "ACBrDFeHttpIndy", e refatorada para não depender da CAPICOM -- ACBrDFeXsXmlSec -- [+] Adicionada nova Unit, derivada de ACBrDFeOpenSSL, criando implementação da classe de TDFeSSLXmlSignClass usando a Lib XMLSEC -- ACBrDFeXsMsXml -- [+] Adicionada nova Unit, derivada de ACBrDFeCapicom, criando implementação da classe de TDFeSSLXmlSignClass usando a Lib MSXML -- ACBrDFeXsMsXmlCapicom -- [+] Adicionada nova Unit, derivada de ACBrDFeCapicom, criando implementação da classe de TDFeSSLXmlSignMsXml usando a Lib MSXML e CAPICOM -- ACBrDFeException -- [+] Adicionado o exception "EACBrDFeExceptionNoPrivateKey" -- ACBrDFeUtil -- [+] Adicionado o método "SignatureElement: String" (por DSA) Obrigado... e considere nos ajudar, contratando o SAC, por pelo menos 1 mês http://www.projetoacbr.com.br/forum/sacv2/sobre/ http://www.projetoacbr.com.br/forum/sacv2/questoes_importantes/ http://www.projetoacbr.com.br/forum/sacv2/cadastro/ Fique atento.... Em breve, organizaremos um Webinar sobre essas modificações

Boa tarde, O padrão do timeout da requisição HTTP para comunicação do ACBr com os webservices é de 5 segundos. ACBrNFe1.Configuracoes.WebServices.TimeOut := 5000; Tive um problema com o webservice de inutilização de NFC-e que me retornava a mensagem abaixo: Erro: Requisição não enviada. 12002 - o tempo limite da operação foi atingido. E resolvi o problema com o aumento do tempo do timeout para 10 segundos. Gostaria de saber se eu aumentar o timeout para 30 segundos para todas as requisições (envio, consulta, eventos, etc) causaria algum problema?

as dicas do posto do FGGLUIZ deu tudo certo, funcionou perfeitamente, obrigado a todos que me socorreu mais uma vez.

@Ailton Branco, boa tarde. Veja o post abaixo:

O post foi perguntando para um rapaz do forum que teve o mesmo problema, mas nao foi resolvido, entao sem querer apertei no botão de postar sem saber para o que servia, até retirei o post.

Ela tem suporte a QRCode.. (página 41 do manual)... mas provavelmente não é 100% compatível com Epson Esc/Pos (não analisei a fundo).. Verifique também a largura do Módulo e correção de erro (faça testes de valores, usando o Demo PosPrinterTeste.exe) Você precisa ajustar o numero de Colunas, para o máximo permitido nessa impressora... e em Fortes, tente ajustar as propriedades "LarguraBobina".. use o SATTeste.exe para testar vários valores...

Isso mesmo. Muito obrigado

Você compila suas aplicações em 64 bits ? Se não, compila, então definitivamente você não leu com atenção os posts..

Já havia sim executado como Adm @Juliomar Marchetti, enfim, fiz a inclusão e registro das dlls manualmente e deu certo. Obrigado.

Aconteceu hoje com um cliente que renovou o certificado dos correios a alguns dias, imagino que seja possível um vírus estar causando esse transtorno, vejam no código abaixo como é fácil excluir a chave privada de um certificado: function Remove-PrivateKey { [CmdletBinding()] param( [Parameter(Mandatory = $true, ValueFromPipeline = $true, ValueFromPipelineByPropertyName = $true)] [Security.Cryptography.X509Certificates.X509Certificate2[]]$Certificate ) begin { # define unmanaged functions to retrieve private key information and delete the key. $signature = @" [DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)] public static extern bool CryptAcquireContext( ref IntPtr phProv, string pszContainer, string pszProvider, uint dwProvType, long dwFlags ); [DllImport("Crypt32.dll", SetLastError = true, CharSet = CharSet.Auto)] public static extern bool CryptAcquireCertificatePrivateKey( IntPtr pCert, uint dwFlags, IntPtr pvReserved, ref IntPtr phCryptProv, ref uint pdwKeySpec, ref bool pfCallerFreeProv ); [DllImport("NCrypt.dll", CharSet = CharSet.Auto, SetLastError = true)] public static extern int NCryptDeleteKey( IntPtr hKey, uint dwFlags ); [DllImport("Crypt32.dll", SetLastError = true, CharSet = CharSet.Auto)] public static extern bool CertGetCertificateContextProperty( IntPtr pCertContext, uint dwPropId, IntPtr pvData, ref uint pcbData ); [StructLayout(LayoutKind.Sequential, CharSet=CharSet.Unicode)] public struct CRYPT_KEY_PROV_INFO { [MarshalAs(UnmanagedType.LPWStr)] public string pwszContainerName; [MarshalAs(UnmanagedType.LPWStr)] public string pwszProvName; public uint dwProvType; public uint dwFlags; public uint cProvParam; public IntPtr rgProvParam; public uint dwKeySpec; } "@ Add-Type -MemberDefinition $signature -Namespace PKI -Name PfxTools $CERT_KEY_PROV_INFO_PROP_ID = 0x2 $CRYPT_DELETEKEYSET = 0x10 $CRYPT_ACQUIRE_ONLY_NCRYPT_KEY_FLAG = 0x40000 } process { foreach ($cert in $Certificate) { # if the current certificate do not have private key -- skip if (!$cert.HasPrivateKey) {return} # if we reach this far and PrivateKey is $null -- the key is CNG key. if ($cert.PrivateKey -eq $null) { $phCryptProv = [IntPtr]::Zero $dwFlags = $CRYPT_ACQUIRE_ONLY_NCRYPT_KEY_FLAG $pdwKeySpec = 0 $pfCallerFreeProv = $false if (![PKI.PfxTools]::CryptAcquireCertificatePrivateKey( $cert.Handle, $dwFlags, 0, [ref]$phCryptProv, [ref]$pdwKeySpec, [ref]$pfCallerFreeProv)) {return} $hresult = [PKI.PfxTools]::NCryptDeleteKey($phCryptProv,0) if ($hresult -ne 0) { $message = "Cert '{0}' failed: {1}" -f $cert.Thumbprint, (New-Object ComponentModel.Win32Exception $hresult).Message Write-Warning $message } } else { # if the key is legacy, then just read the PrivateKey object of the X509Certificate2 object $phProv = [IntPtr]::Zero if (![PKI.PfxTools]::CryptAcquireContext( [ref]$phProv, $cert.PrivateKey.CspKeyContainerInfo.KeyContainerName, $cert.PrivateKey.CspKeyContainerInfo.ProviderName, $cert.PrivateKey.CspKeyContainerInfo.ProviderType, $CRYPT_DELETEKEYSET)) { $hresult = [Runtime.InteropServices.Marshal]::GetLastWin32Error() $message = "Cert '{0}' failed: {1}" -f $cert.Thumbprint, (New-Object ComponentModel.Win32Exception $hresult).Message Write-Warning $message } } } } } The usage is pretty simple: just pass a certificate object, and the function will delete private key when necessary. The function performs all required checks to properly handle various scenarios. Few considerations should be taken into account prior to using this function: This function DO NOT delete certificate from the store. The whole purpose of this function is to delete the private key. If two or more certificates share the same key, all they will stop working. If the key is stored on a hardware (smart card, HSM), the function call may raise a PIN dialog, where you will have to enter the PIN to access the private key. O código foi retirado de https://www.sysadmins.lv/blog-en/how-to-properly-delete-certificate-with-private-key-in-powershell.aspx e não testei se funciona com os tokens que usamos, mas a hora que tiver um tempo vou gravar uns certificados fakes em uns cartões que tenho aqui e testar. Isso prova a facilidade em excluir objetos no token, e qualquer coisa pode ser o culpado, inclusive um vírus. Só acho inadmissível essa fragilidade nos certificados.

Bom juliomar, Estou usando enviarsincrono e coloco para não consultar lote ao apos o envio, após consulto por NFSe por RPS. (Somente o protocolo que não tem) PS: No modo Enviar, o lote fica esperando processamento. Espero ter ajudado Abs

Bom dia, Testado. OK. Obrigado, Renato Rubinho Analista de Sistemas http://linkedin.com.br/in/renatorubinho

É sempre bom lembrar, que os fontes do ACBr, apenas abrem o Certificado como "ReadOnly".. Veja o código abaixo, de ACBrDFeWinCrypt.pas FpStore := CertOpenStore( StoreProvider, 0, 0, StoreFlag or CERT_STORE_READONLY_FLAG, LPCTSTR( FpDFeSSL.StoreName ) );

Bom dia pessoal. Só para ficar registrado, consegui fazer a Argox OS-214plus não desperdiçar etiquetas com o componente ACBrETQ, mas nada das dicas que encontrei resolveram para mim, apesar que para outros funcionou, como a descrita nesse tópico pelo @Ederaldo, ou outras que encontrei pela internet: https://argoxbrasil.blogspot.com.br/2013/04/como-habilitar-o-back-feed-para-argox.html No meu caso, que efetuo a comunicação diretamente pela LPT1 via mapeamento do compartilhamento da impressora, só funcionou ao utilizar na função Imprimir o parâmetro avanço ( ACBrETQ.Imprimir(1, 600) ), com valor 600, não sei nem dizer exatamente o porque desse valor, no desespero fiz na tentativa e erro e funcionou bem para todos os modelos de etiquetas que estão implementadas no sistema com GAP, variando desde a menor com altura de 18 mm até a maior com 50 mm, em todas o avanço foi de 600, funcionando perfeitamente o backfeed. O que acho estranho de ter de fazer isso para Argox (com linguagem PPLA), foi que para impressoras Zebra e Bematech LB-1000 (com linguagem EPL2) nunca foi necessário utilizar o parâmetro avanço e funciona normalmente até hoje ( ACBrETQ.Imprimir ). Emfim, o fato é que está finalmente funcionando, resolvi compartilhar como solucionei o meu caso para quem sabe possa ser útil para mais alguém que venha a passar por isso. Fabrício Gomes Araújo

Não faço parte do Governo, e não sou fabricante de SAT... mas acho que o SAT é uma ideia infinitamente melhor e mais robusta do que a NFCe... Nosso software atende PAF-ECF, NFCe e SAT... ( www.djpdv.com.br ) e minha opinião, é que a NFCe é um "filho mal parido da NFe"... Autenticação online, para varejo ?? Resultado: fila nos caixas dependendo do horário... Nosso software faz o tratamento automático da entrada e saída de contingência, trabalha em Background na transmissão da fila do OffLine, e na resolução de outras pendencias... Muita da inspiração que tivemos na construção de nosso módulo emissor de Documentos Fiscais, veio da observação do funcionamento do SAT. Mas mesmo assim, nosso suporte, sofre com o NFCe... Cada estado tem uma peculiaridade, a Internet no interior do Pais é intermitente e de qualidade lastimável... então o que podemos observar, é que a experiência de uso do usuário com o SAT, é infinitamente melhor do que do usuário de NFCe... Se o fisco fizesse cumprir o rigor da lei, que obriga a transmissão dos XMLs emitidos em OffLine, em até 24 hs úteis, muitos estabelecimento já teriam fechado as portas... O projeto NFCe é uma péssima ideia para o varejo...mas que está sendo remendada aqui e ali, e vai funcionar aos trancos e barrancos... Sinceramente, o varejo estava bem melhor com os ECFs, do que com a NFCe. O projeto SAT por sua vez... demorou 3 anos para nascer, o fisco de SP fez inúmeras consultas públicas, convocando setores do varejo, fabricantes e Sw.Houses de Automação Comercial. Tudo isso para mitigar os problemas e deixar bem clara as regras e normas de uso. O Fisco foi aberto a sugestões, e criou uma especificação técnica clara, consistente e que funciona... O SAT, passou por um período de ajuste... Alguns fabricantes sofreram até deixar seus Sw.Básicos e DLLs robustos o suficiente para o uso.. O retaguarda do Fisco apresentou inumeradas falhas (reconheço que algumas ocorrem ainda hoje em dia)... Mas hoje, podemos afirmar, que o SAT está muito mais maduro e robusto do que a NFCe... e o que percebemos no uso dos clientes finais, é a filosofia: "Instale e esqueça"... pois depois de instalado o SAT, ele funciona sozinho... Porque vocês acham que SP não permite NFCe off-line ? Alguns estados, já perceberam o grande aumento da sonegação fiscal, quando passaram a permitir: offline + impressora não fiscal nos caixas... (afinal o empresário Brasileiro, não paga imposto só porque que é patriota) Os números falam por si... Quem esteve na última reunião do ENCAT pode presenciar... Atualmente, SP já autorizou mais CFe's (SAT), do que a soma de todas as Unidades Federativas do brasil autorizaram NFCe's. Incluindo nessa conta.. as milhares de NFCe's que o próprio SP emite...

No meu caso eu deixo os cancelados pois trabalhamos com supermercados e para controle, vai precisar dos cancelados. quando faço a transmissão eu recrio a sequencia dos itens