Daniel Simoes

Não que eu saiba... Não seria mais simples obter essa informação do BD da aplicação ?

Uma maneira rápida de corrigir as URLs de sua aplicação que usa o ACBr, sem necessariamente instalar um novo programa, é atualizar o arquivo de Endereços dos WebServices, diretamente na máquina local Baixe o arquivo ACBrNFeServicos.ini, clicando na URL http://svn.code.sf.net/p/acbr/code/trunk2/Fontes/ACBrDFe/ACBrNFe/ACBrNFeServicos.ini (clique no link com o botão direito do Mouse, e Salvar Como..) Salve o arquivo ACBrNFeServicos.ini exatamente na mesma pasta do seu .EXE Feito isso, o ACBrNFe passará a carregar as URLs de WebServices desse arquivo, ao invés do resource interno do componente Lembre-se de atualizar o arquivo ACBrNFeServicos.ini a cada atualização do sistema

Você poderia usar o evento FormKeyPress e tratar essas teclas, para chamar métodos do componente do acesso ao BD

Cross Compile de Linux64 para Linux32 (Fonte: https://wiki.freepascal.org/Cross_compiling#From_Linux_x64_to_Linux_i386 ) Você precisará do Linker em 32 Bits... ou mais precisamente do arquivo i386-linux-ld No meu OpenSuse, esse binário pode ser instalado pelo pacote cross-i386-binutils, portanto... (em modo root) zypper install cross-i386-binutils zypper install cross-i386-gcc9 Porém o OpenSuse irá instalar esse binário com um nome ligeiramente diferente, então basta fazermos um link simbólico para o nome esperado pelo FPC (em modo root) ln -s /usr/bin/i586-suse-linux-ld /usr/bin/i386-linux-ld ln -s /usr/bin/i586-suse-linux-as /usr/bin/i386-linux-as Acessar pasta dos fontes do FPC cd /usr/share/fpcsrc/3.0.4 Compilar FPC em Linux 32 (em modo "root") make all OS_TARGET=linux CPU_TARGET=i386 Instalar novas DCUs e Compilador no Linux (em modo "root") make crossinstall OS_TARGET=linux CPU_TARGET=i386 INSTALL_PREFIX=/usr Você precisará ter todas as Libs que o seu software depende, instaladas no seu sistema Linux, na versão 32 bits... Exemplo: /usr/bin/ld: não foi possível localizar -lpthread /usr/bin/ld: não foi possível localizar -lgdk-x11-2.0 .... Isso significa que precisamos ter no sistema as libs (libpthread.so e libgdk-x11-2.0.so) em algum diretório do LibPath para Libs de 32 bits (/lib ou /usr/lib) Resolva passo a passo as dependências, Provavelmente seja mais fácil usar o utilitário yast, para procurar as Libs faltantes, na versão 32 bits.. Instalando os pacotes abaixo, provavelmente você resolverá várias das dependências... zypper install glibc-32bit zypper install glibc-devel-32bit zypper install libgthread-2_0-0-32bit zypper install libgtk-2_0-0-32bit zypper install libgdk_pixbuf-2_0-0-32bit zypper install libpango-1_0-0-32bit zypper install libX11-6-32bit zypper install libxml2-2-32bit Se necessário, crie links simbólicos para os nomes corretos (terminando em .SO)... Exemplo: cd /lib ln -s libpthread.so.0 libpthread.so ln -s libc.so.6 libc.so ln -s libdl.so.2 libdl.so cd /usr/lib ln -s libglib-2.0.so.0 libglib-2.0.so ln -s libgmodule-2.0.so.0 libgmodule-2.0.so ln -s libgthread-2.0.so.0 libgthread-2.0.so ln -s libgobject-2.0.so.0 libgobject-2.0.so ln -s libgtk-x11-2.0.so.0 libgtk-x11-2.0.so ln -s libgdk-x11-2.0.so.0 libgdk-x11-2.0.so ln -s libgdk_pixbuf-2.0.so.0 libgdk_pixbuf-2.0.so ln -s libatk-1.0.so.0 libatk-1.0.so ln -s libcairo.so.2 libcairo.so ln -s libpango-1.0.so.0 libpango-1.0.so ln -s libpangocairo-1.0.so.0 libpangocairo-1.0.so ln -s libX11.so.6 libX11.so ln -s libxml2.so.2 libxml2.so Compile novamente e verifique se ainda restam dependências de Libs, no caso de novo erro... cheque novamente se as libs indicadas nas mensagens de erro, estão em /lib ou /usr/lib (ou com o nome semelhante ao esperado) Editar /etc/fpc.cfg, para configurar corretamente o Path da gcclib em 32 e 64 bits (em modo "root") # path to the gcclib #ifdef cpui386 -Fl/usr/lib64/gcc/i586-suse-linux/9 #endif #ifdef cpux86_64 -Fl/usr/lib64/gcc/x86_64-suse-linux/9 #endif Configure o seu projeto, criando um novo Build Mode (em modo normal) Acesse Project Options -> Compiler Options -> Config and Target Target OS -> linux Target CPU -> i386

Apenas SP aceita SAT... Nesse mapa (link abaixo) você pode ver as tecnologias fiscais por estado https://www.projetoacbr.com.br/acbr-mapas-fiscais/

Legal @Saulo Nunes... As modificações promovidas pelo @Italo Jurisato Junior, foram necessárias ?

Não necessariamente... o erro 500 ocorreria se o servidor não compreendesse o SOAP de entrada... Compare o ped-eve-soap.xml com o do site do servidor

Talvez o SOAP não esteja batendo com o esperado... https://homologacao.nfce.epec.fazenda.sp.gov.br/EPECws/RecepcaoEPEC.asmx?op=nfeRecepcaoEvento

A Community não deveria realmente ser instalada em um ambiente, de empresa, que não atenda as exigências de "micro desenvolvedor"... (isso está descrito no Termo de aceite da instalação) Mas concordo que poucas pessoas sabem disso, e isso acaba representando um risco... ou seja, muitos confundem a Community com um Trial Creio que você possa fazer do Limão uma limonada... O melhor momento para comprar Delphi é agora... pois até o final desse mês, eles tem um desconto de 30% para quem tem qualquer versão do Delphi antigo (Anistia) O @Régys Silveira é revendedor da Embarcadero, e pode lhe auxiliar nisso...

Vou pedir para meus contatos na Embarcadero analisarem o seu caso...

Nunca tentei

Infelizmente não Delphi ou FMX... não terei condições de ajuda-lo....

Pelo que notamos... o arquivo eventoEPEC_v1.00.xsd, disponibilizado pelo Sefaz, não está em alinhado com a versão 4.0 da NFCe... Acho que niguém usa o EPEC como contingência para NFCe em SP... tendo em vista que é obrigatório a presença de um SAT, para casos de contingência da NFCe, em SP Convêm interrogar o SEFAZ, por um Schema de EPEC mais atualizado

Sim é possível... Veja a aplicação de Demo, na pasta "Exemplos\ACBrSerial\"

Sim.. o que indica que o problema é em algum XSD especifico... Cada WebService irá carregar um (ou vários) XSD... Com o Debug você conseguirá verificar exatamente, qual o nome do arquivo XSD que está com erro na carga (corrompido)... Após isso precisamos comparar esse XSD com o original, fornecido pelo Fisco

Schema inválido, significa que a LimXML2 não conseguiu carregar o arquivo XSD... ou seja, pode ser que o arquivo esteja corrompido..

O FortesReport já compila em Linux... porém no Lazarus... como o código é 100% pascal, creio que não haverá muito dificuldade em compila-lo na FMX Linux... Mas creio que será necessário testar e efetuar pequenos ajustes

Parece ser alguma configuração no Spool do Windows.. Configure para não fazer Spool Mas o mais indicado é usar EscPos.. pois nesse caso você não precisará nem do Driver da Impressora

Use LibXML2... Configure SSLlib que ela já configura as outras 3 bibliotecas de Criptografia, Transmissão e manipulação de XML

o Hook só funciona para Impressoras não fiscais (ACBrPosPrinter)... para ECF, o componente é o ACBrECF...

o suporte a MSXML (obviamente), é desativado no Linux... e deve ter ficado gravado no Demo, essa configuração... Basta ignorar o erro... mudar algo no Form, e salvar o projeto... Use libOpenSSL,

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

ECF já morreu... mas em todo caso... a Bematech não tem um método TXRX, em sua DLL, que nos permitiria fazer um Tunel pela DLL para acessar a USB