Régys Silveira

apague os arquivos ACBrECF.pas e ACBrECFClass.pas e atualize.

Outro usuário me relatou o mesmo problema, e parece que MG entrou e contingência porque o webservice estava instável e com problemas.

As bases de cálculo do ISSQN estão zeradas: U|0.00|3.84|6.91|3503307|101|N| U|0.00|3.84|10.37|3503307|101|N|

Sim isso para a geração ficou bacana, o problema é quando ler um arquivo XML que está zero no cNF, o componente vai gerar um código, dai os dados não vão bater.

Tem algo errado, estes dois arquivos que você enviou não são gerados pelo método PafMF_LMFC_Cotepe1704. Acabei de testar ele aqui gerei vários arquivos e está tudo correto, você não fez nenhuma alteração nos teus fontes ai?

Você vai gerar: R04 - 1 registro dos dados do cupom R05 - 3 registros dos itens R06 - 1 registro do CDC R07 - 2 registros das formas de pagamento

Desculpe mas quando você disse "importo para o componente acbr" o que dá a entender é uma rotina que pega o arquivo e preenche o componente, por isso te passei os campos.

A alteração funciona para a geração do xml, mas não para a leitura dele, como vai estar zero o componente vai gerar um código númerico, o que está errado. Conversando aqui achamos melhor colocar uma propriedade no componente para dizer o que fazer (gerar ou não o código).

Acabei de enviar um acerto, atualize e verifique se continua a ocorrer, se sim me passe como está chamando a função no delphi, inclusive os parâmetros.

Na verdade o problema e que o LMFC e gerado por intervalo de CRZ, dai termos a função para passar para COO, porque as funções da dll utilizam o COO.

Boa tarde, existem diversos tópicos discutindo essas alterações, por favor efetue uma busca no fórum.

tente colocar o enabled do form como false e depois de feito retorne para true.

Vou olhar isso então.

O servidor de MG parece estar com problemas, está ocorrendo "loucuras" com a NFe também.

Fiz uma alteração na rotina e enviei para o SVN, agora ela passa a procurar pelo início da lista, o que resolve o problema relatado.

O demo da bematech funciona porque ele trabalha diretamente com o emulador. Independente de ter placas de porta COM você precisa criar as portas virtuais, se não tem como conectar o ACBr ao emulador.

Você deve utilizar as propriedades: Det[].Imposto.ICMS = para ICMS Det[].Imposto.ISSQN = para Serviço

Não, não tem nada no ACBr para vender duas vezes, hehe. Faça o teste com o ECFTeste dentro da pasta "\exemplos\ACBrECF" e verá que é tudo normal. Aqui eu tenho clientes bem grandinhos com cupons de 300, 500 itens e nunca ocorreu isso.

Olha isso e alguma coisa na sua rotina, faça os teste no ECFTeste e verá que não ocorre isso.

O manual da nota eletrônica diz o seguinte para o cNF: "Código numérico que compõe a Chave de Acesso. Número aleatório gerado pelo emitente para cada NF-e para evitar acessos indevidos da NF-e. (v2.0)" Então a rotina está trabalhando corretamente hoje, conforme o manual é errado gerar sempre como o valor "0".

É assim mesmo, você tem o manual e as posteriores correções, até que eles lancem uma versão nova do manual, não tem outro jeito.

Podem ser diferentes, a unidade comercial é como você vende a unidade tributaria e como você tributa. Acontece muito em atacados e similares.

Poste o xml da nota, senão não tem como ajudarmos.

printa a tela de erro e posta aqui, por favor.

Alguma coisa está errada com os teus arquivos, já tem algumas versões que mudamos os dois métodos para ACBrUtil.pas e retiramos de ACBrNFeUtil.pas, algo não deve ter deixado atualizar ai. Veja se estes arquivos na hora de atualizar não estão em conflito com o repositório, isso acontece geralmente quando se altera algo no arquivo. Olhando dentro do diretório os arquivos devem estar com o tick verde, qualquer outro simbolo significa que ele está diferente do que está no repositório.