WesleyAS

Apesar de alguns erros no ambiente de homologação da Multiplus (situações específicas onde uma chamada de função administrativa retornava como sendo uma venda no cartão), conseguimos finalizar com sucesso os testes.

Segue os arquivos atualizados. Fiz os testes básicos com cartão de crédito, débito e PIX. Agora vou ver com a Multiplus como seria a homologação. ACBr.zip

Fiz uma correção porque a confirmação da operação ficava em loop. Ainda estou fazendo os testes para validar todas as operações. Assim que estiver correto eu posto aqui novamente para análise.

Bom dia! O TEF da Multiplus Card funciona como um Discado, sem a necessidade de alterações no componente atual. Porém eles tem a opção para fazer a comunicação por Web Service, assim não existe a troca de arquivos e sim o envio do conteúdo por meio de request's em duas rotas. Fiz a implementação inicial no componente ACBrTEFD, sobrescrevendo as rotinas que utilizavam os arquivos de controle. Cheguei a estudar a implementação no componente ACBrTEFAPI, mas fez mais sentido deixar no outro componente mesmo. Estamos implementando esta comunicação por Web Service pois alguns clientes começaram a utilizar nosso sistema de forma remota (Terminal Server), mas o TEF precisa rodar localmente pois cada usuário precisa tem uma instalação/pasta para fazer a troca de arquivos. Me parece que a PayGo também possui algo desse tipo. Os arquivos com as alterações estão em anexo para análise, junto com a documentação que a Multiplus nos enviou. ACBr.zip Guia Integração Multiplus Card - WEB SERVICE.pdf WEBSERVICE - Exemplos básicos.postman_collection.json

O erro 964 era pra estar desativado já, mas o 744 ainda não.

O erro é apenas na NFC-e mesmo. Não tenho o contato direto dele, mas nosso contador conseguiu num grupo nacional de contabilidade.

Aparentemente foi erro da SEFAZ aqui em MT, inclusive nos informaram que vão desativar a regra 969.

Achei o maldito erro. No nosso caso o código do serviço estava sendo formatado, numa rotina antiga, com zero a esquerda ("0107") e deveria ser enviado apenas "107". Eu não tinha percebido o erro porque as filiais que estão funcionando o código do serviço é "1401".

Já fiz esta verificação do XML e não encontrei nada deste tipo. Os únicos dados que são diferentes são: IdentificacaoPrestador.ChaveDigital IdentificacaoPrestador.Cnpj IdentificacaoPrestador.InscricaoMunicipal ItemLei116AtividadeEconomica AliquotaISSQN DadosServico.Discriminacao DadosServico.CodigoCnae Os dados do tomador e os valores são os mesmos. Já esses campos acima são específicos, pois as empresas que estão funcionando são de assitência técnica de informática, e a outra é justamente a Software House.

Aqui estamos com esse erro também, porém apenas uma empresa do grupo. As outras 4 estão emitindo normalmente - todas com o sistema no mesmo servidor/banco de dados. Comparei o XML do RPS gerado e estão praticamente iguais, com apenas os dados do emitente/prestador do serviço diferentes. Também não obtive resposta da Agili até o momento.

Funciou a atualização. Obrigado.

Foi implementado para o provedor Agili uma quantidade mínima de RPS por lote, porém quando é utilizado a opção de emitir de forma unitária - Emitir('1', meUnitario, False) - acaba gerando um erro pois a quantidade máxima de RPS é 1 e a quantidade mínima é 2. Essa alteração foi enviada na revisão 30752 pelo @Italo Giurizzato Junior Vou analisar o fonte pra ver qual seria a melhor maneira de corrigir.

Esses testes são novos que apareceram no roteiro 3.01 de 04/04/2017, por isso que muita gente começou a cair nesse problema. Na página 2 do roteiro tem o histórico de alterações: Não sei quando foi liberado a versão do simulador Pay&Go que contemplava essa versão do roteiro, por isso pode ser que voce tenha feito a homologação antes desses testes se tornarem obrigatórios.

Marcou a nova propriedade do componente? Porque por padrão eu tinha deixado ele desmarcado.

Eu não utilizei esse valor reajustado, apenas tinha deixado pronto pra caso precisasse. Pelo que eu vi no exemplo do ACBr esse campo "ValorTotal" não esta sendo utilizado - está apenas mostrando num "memo" como log. Pode ser que precisamos guardar esse valor para um cancelamento posterior. Já no componente existe mesmo alguns tratamentos para saber o saldo restante mas não me aprofundei nisso. Talvez quem pode nos ajudar com essas dúvidas seja o @Roberto Kenji Yoshino, representante da NTK.