PC Toledo

Boa tarde caros.

Esse problema já ocorre há tempos. Inclusive numa ocasião entrei em contato com o suporte da Daruma, mas infelizmente não me deram ouvidos.
No código abaixo:
O parâmetro aliq é o índice da alíquota no emissor de cupom fiscal.
(A impressora fiscal possui uma lista de alíquotas, então eu passo a posição desta alíquota.)

Quando é passado algo como '01', '02, '03', etc ... na saída da função a variável está com o mesmo valor intacto.
Porém, se eu passar 'FF', 'II' ou 'NN' que também podem ser usados, na saída da função estes valores ficam alterados respectivamente em '17', '18' ou '19' !!!
E o mais intrigante: notem que antes da chamada a DLL, eu salvei na variável alyq o valor de aliq. E após a chamada a DLL, a mesma também tem o seu valor alterado !!!

Eu não posso atualizar para a DarumaFrameWork por questão minha aqui, mas a Daruma32 que utilizo em meus clientes é a mais atual.
Quando entrei em contato com o suporte da Daruma, o atendente não quis ouvir, e sugeriu que utilizasse o valor % da alíquota ao invés do índice, o que para mim não é possível, haja vista outros procedimentos que utilizam o índice.

Algum dos colegas tem alguma sugestão ?

Como está sua declaração?

Porque você simplesmente não faz uma conversão para voltar ao texto que você quer?

Prezado desenvolvedor,

De fato portar a sua app para a DarumaFramework.dll é o melhor caminho, pois alem de voce ter suporte completisso nesse driver, voce tem tambem a possibilidade de passa o indice da referida posicao de memoria, que a dll resolve.

Exemplo: se voce passar 17, a DarumaFramework.dll ira registrar o item no cupom fiscal com F1, que é equivalente a posição de memória de indice 17.

... editado ...

Att.

Como eu citei no tópico inicial: não é possível para mim fazer esta troca de dll´s, estou envolvido com outras rotinas que tem maior prioridade hoje. O problema maior é que todos os meus clientes usam Daruma, por indicação minha.
No help da Daruma32.DLL é exatamente isso que está orientando a fazer: o parâmetro pode ser passado com o valor do índice na lista de alíquotas do ECF, ou o valor em %.
Eu utilizo passar o índice na lista, por questões internas minhas. Porém quando eu passo na variável os valores 'FF', 'II' e 'NN', esta variável tem o seu valor alterado (após a chamada da função de venda) para '17', '18' e '19', bagunçando toda a retaguarda que cuida da parte contábil e fiscal como Sintegra e outros bichos do tipo.
Na época em que solicitei o suporte da Daruma e reportei este bug (pois é um bug na DLL, não tem outra explicação), não fui levado à sério.
Hoje já resolví de outra forma, até poder atualizar o sistema para usar a DarumaFramework.

Indique a solução utilizada para ajudar outras pessoas que possam estar enfrentando o mesmo problema.

A solução foi buscar no banco de dados, o índice da alíquota no ECF. Ignorando a variável que fora usada para enviar o comando à DLL.

A solução que o Samir sugeriu, concluí não ser muito precisa, pois não encontrei uma lógica nos tais valores 17, 18 e 19.

É isso aí.

alaminojunior escreveu:concluí não ser muito precisa, pois não encontrei uma lógica nos tais valores 17, 18 e 19.

Olha, até aonde eu entendo a ECF vem com 16 posições que são permitido a gravação de alíquotas. Com isto vc terá do índice 1 ao 16 (customizável)
as posições 17/18 e 19 são fixas e reservadas. (Já vem de fábrica setado para FF - II - NN ).
Então se eu tenho apenas um índice exemplo o 1 em 18% e um produto com substituição, ao usar o índice 17 o produto estará indo para o totalizador FF.
Não sei se em todas são assim, mas a lógica é esta.

Não sabía desta! Obrigado pela luz.

Mas o problema não é este, e sim o fato da função na DLL estar alterando o valor da minha variável.

Acredito que a minha lógica se ajuste a sua necessidade, verificou se 17/18/19 equivale a FF/II/NN ?