Daniel Simoes

Esses métodos não são normatizados pela Especificação técnica do SAT (são exclusivos desse fabricante)... e portanto não serão incorporados no ACBrSAT

Não há configurações de porta no ACBrSAT.... ele simplesmente acessa a DLL do fabricante, e esta é quem acessa a porta... Portanto, pergunte para o fabricante, como configurar a DLL para acessar uma porta específica

veja esse tópico, que explica como o windows procura as DLLs existentes na máquina http://stackoverflow.com/questions/2463243/dll-search-on-windows

É isso mesmo que precisa ser feito... esse ECF tem um comportamento diferente dos demais... que já fazem o corte automático...

Por favor envie uma Imagem, com os campos que você está mencionando, em destaque

Você usa o ACBrPosPrinter ?

Não tenho nenhuma impressora da Daruma... não posso lhe ajudar a respeito desse fabricante...

Tem um flag nesse equipamento, que habilita o Corte após o rodapé... deve estar desabilitado... Acho que dá pra ativar isso, mesmo fora de intervenção, com um programa do Fabricante... Veja esse tópico: Nele é citado, que isso pode ser uma característica desse equipamento... ou seja, ele NÃO envia o corte de papel de forma automática... e que caberia a aplicação fazer isso

Não.. o ACBrMail não usa a WinlNet API... ele usa o OpenSSL... Você deve estar com versões inferiores a 1.0 da OpenSSL

Faça testes com os ECFs virtuais... com eles você poderá usar NFCe e SAT de forma semelhante a um ECF

Obrigado pela contribuição.. Já no SVN...

Boa pegada... e a UnitTeste se comportou bem no Lazarus... Já está no SVN...

Quem faz a carga de DLLs é o Sistema Operacional e nao o ACBr O windows lê as DLLs de acordo com o seu Path

1 Byte ?? Parece ser muito pouco, você terá uma baixa performance na impressão

Essas informações não vem do Gerenciador TEF, você precisaria ter uma tabela no seu sistema, e fazer uma referência cruzada

Sim, pois como o valor é informado de fora... ele pode não vir formatado corretamente em 2 casas Use os testes Unitários do ACBr, e verifique porque você tem esse resultado estranho com "TruncTo"

Fique a vontade para propor melhorias nos fontes... Use as UnitTestes, para saber se não quebrou algo...

Não compreendo... TruncTo(78.22, -2) nunca poderia retornar 78,21... Sugiro você testar a UnitTeste do projeto "ACBrComumTesteCase", para testar o método: TruncTo Introduzi o seguinte teste nela... que rodou sem problemas... procedure TruncToTest.As199Double; var VValor: Double; begin VValor := 1 * 78.22; CheckEquals(78.22, TruncTo( VValor, 2 ), 0.001); end;

As modificações já estão no SVN... acho que logo o @Celso, compila uma nova versão...

Sugiro que você interaja no tópico indicado, para apurarmos o problema...

Pode ser que você tenha que definir um limite no Buffer de Recepção: Exemplo, para definir 8K de Buffer Serial ACBrPosPrinter1.Device.SendBytesCount := 8192;

Se já funcionava para a NFCe, então tem que funcionar para NFe 4.0... afinal é o mesmo código, e como você mesmo comprovou, ele está sendo executado... Veja o exemplo de preenchimento de Tags do Pagamento da NFCe no Demo do ACBrNFe... Verifique se você está conferindo o XML no local correto. Verifique se alguma outra rotina está modificando o XML assim que o mesmo foi gerado

Há alguns erros no seu XML... - Ele está endentado (com espaços) - A tag de assinatura está diferente do esperado: <SignatureValue Id=" Segue exemplo de um bloco de assinatura, válido: <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#NFe35161205481336000137550010000001111000001111"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>gAwRwNZVCHp5+OOs4VDOJ3IN5dU=</DigestValue> </Reference> </SignedInfo> <SignatureValue>LzQ79v9KyOxXsLiLWb88uSvtZeQFGO+k0zIJxhfKDiB53q8+IeUQLoiFP3IZ8InohatTRH3Dws0b634Tky2fB3eMS6m7aE912oNIrKjJcwlVCp4itaNwXPtusjl8d6HAtt4WLNvsZ5KK1SlOqmSOXokF5cIGChfeKmbktWXjvXUUNFalsLqs3x45KQwblu6qKrmd6G68byWjp0W2Wchp6omdn6cx9qaLhx3rWZhOvTnA7lQMQVMJHbojsUFnxmxnzorXzGFvmuhWI23kKtEUfdZd5vve/lWuRjCgU1gkZSLdCYLL5g9+QxAQIT9b2CqJjjuWEnPyYbSzpYl4T/j5GQ==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIIBjCCBe6gAwIBAgIQZwvuC5FC/T1b/cOv8b4T0jANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDE2MDQGA1UECxMtU2VjcmV0YXJpYSBkYSBSZWNlaXRhIEZlZGVyYWwgZG8gQnJhc2lsIC0gUkZCMRUwEwYDVQQDEwxBQyBCUiBSRkIgRzMwHhcNMTYwNDE0MDAwMDAwWhcNMTcwNDEzMjM1OTU5WjCB8DELMAkGA1UEBhMCQlIxEzARBgNVBAoUCklDUC1CcmFzaWwxCzAJBgNVBAgTAlNQMQ4wDAYDVQQHFAVUYXR1aTE2MDQGA1UECxQtU2VjcmV0YXJpYSBkYSBSZWNlaXRhIEZlZGVyYWwgZG8gQnJhc2lsIC0gUkZCMRYwFAYDVQQLFA1SRkIgZS1DTlBKIEExMSYwJAYDVQQLFB1BdXRlbnRpY2FkbyBwb3IgQVIgQ09ORklBTUFJUzE3MDUGA1UEAxMuRCBKIEFVVE9NQUNBTyBDT01FUkNJQUwgTFREQSBNRTowNTQ4MTMzNjAwMDEzNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANxLskZpFozgeXwBd98r4ZOpig7zsPSIHLRcaaF3OqgzPzg0KFdokRL8F8O0edMSuQfVjtPjOAIEadTB/YvWDbtfiYdT2TLTcJhAJqSXRGJhDEDOMf3X+d8HcaVopPRKIeTAuabtoHPSYHox6AGdD6fZrp58x84FAWtBfnu+qoEGHF1L86YFR0YZ9Ryd8KMa5LHPbC5dpedsmXxvPYnrhXJ0tVcTYLW9zdHxzw7ux2pK6hVS4HGEadg5KIqqamYogaNI444ly+G09YFThfQhxyMVy/UqQVLEOqx5sp3Bom/eL2ZQz6ZnE+PLK3Y8mWHvmgxEOuXUiQ/oTH5i4/sQZIkCAwEAAaOCAxgwggMUMIHABgNVHREEgbgwgbWgPQYFYEwBAwSgNAQyMTgwODE5NzExMjI5ODczODgwNzAwMDAwMDAwMDAwMDAwMDAwMjA1ODAxMzI4U1NQU1CgJgYFYEwBAwKgHQQbSkVGRVJTT04gR0FCUklFTCBERSBBTE1FSURBoBkGBWBMAQMDoBAEDjA1NDgxMzM2MDAwMTM3oBcGBWBMAQMHoA4EDDAwMDAwMDAwMDAwMIEYcGF0cmljaWFAZGpzeXN0ZW0uY29tLmJyMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUTvuocXG/6qm9kT1NumSs+dLi5KQwDgYDVR0PAQH/BAQDAgXgMGwGA1UdIARlMGMwYQYGYEwBAgEbMFcwVQYIKwYBBQUHAgEWSWh0dHA6Ly9pY3AtYnJhc2lsLmFjYnIub3JnLmJyL3JlcG9zaXRvcmlvL2RwYy9BQ19CUl9SRkIvRFBDX0FDX0JSX1JGQi5wZGYwgfQGA1UdHwSB7DCB6TBLoEmgR4ZFaHR0cDovL2ljcC1icmFzaWwuYWNici5vcmcuYnIvcmVwb3NpdG9yaW8vbGNyL0FDQlJSRkJHMy9MYXRlc3RDUkwuY3JsME+gTaBLhklodHRwOi8vaWNwLWJyYXNpbC5vdXRyYWxjci5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL0FDQlJSRkJHMy9MYXRlc3RDUkwuY3JsMEmgR6BFhkNodHRwOi8vcmVwb3NpdG9yaW8uaWNwYnJhc2lsLmdvdi5ici9sY3IvUkZCL0FDQlJSRkJHMy9MYXRlc3RDUkwuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCBjgYIKwYBBQUHAQEEgYEwfzBTBggrBgEFBQcwAoZHaHR0cDovL2ljcC1icmFzaWwuYWNici5vcmcuYnIvcmVwb3NpdG9yaW8vY2VydGlmaWNhZG9zL0FDX0JSX1JGQl9HMy5wN2MwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwLmNlcnRpc2lnbi5jb20uYnIwDQYJKoZIhvcNAQELBQADggIBAGcdNFrI6udZ25VIu+9ehJkiIAdTEmTlayzfz9u/o0I1hmBfJpx5/SEiDdKr3ehfU7zSPGNJEP4Mk0+CSr+gV1gkv0WFREheZolZ/iddMXYlnIa2vw27t6bV4zjPVnljE6yRUNWxYw8Fz9b5sircMX9Xhx4Dh9VfWVSY4JqbSseu8Hc93Er02DcHtMATKzEdsj8pJCyIoqLR3ORgsI2W2gK8XpZT05y9wG3lqiELQRUv3WYozHTZI2uibjfT/1AZCAHaCFx3ngeCOqiELAgK/adSQ3+7XV+s8NybR2j862tEY0+Z4GZv8ALvsSrtNBkr0799I0FZ271WHmFaVwq78hEeK1dDPeQkfveaEx6zwYjIJ2QvGF8VsRD1tMQVf2TIwpUPdwtDcK3VsaGGqux/z2FStszEcfIv32eUNWGaK/nWWo9FsdFoYipjI9sSsaydcg4HRNpwod0ZN6ZNBIbs2ONIIvkui1uGLnhU7DYWzJk2d7PrHfyJ2TlZ0yNhuYDA8K5yJJBLeBQHRJBDUGF+EuVT2LIYbhhCpPrmOOtYXzj2VX88xczTK50nlKj/TeHTEx8SEj5cSUOdI7Nwj0D4X+kIIhoeE/Sanhbho+Q1FSXAqvHJDaYwKyH/ojMbOSrL1tL6/8Fz+FSoICtT5xGrXpPYcHXojbx8HxtJc5a7meel</X509Certificate> </X509Data> </KeyInfo> </Signature> Com isso, ao ler o XML, o ACBrNFe, não reconhece que o mesmo está assinado, e despreza as informações da assinatura

Não... seu sistema irá parar de gerar CFes válidos... os equipamentos são atualizados de forma compulsória, pelo SEFAZ

Apliquei um possível ajuste no SVN...