Rômulo da Costa de Souza

Bom dia Italo, Segue em Anexo o Arquivo pnfsNFSeW.pas com a mudança, obrigado. pnfsNFSeW.pas

Bom dia Italo, Vou analisar os códigos do ACBR e ver o que podemos fazer, hoje sei que para estes 2 provedores "Pronim e Betha", o CodigoMunicipio deve receber o MunicipioIncidencia, quando o tomador do serviço for de um município que difere do emitente.

Boa tarde Pessoal, Primeiramente gostaria de parabenizar pela iniciativa, acredito que com o esforço de todos nós possamos alavancar este projeto... Obtive o tortoise e dei uma analisa no que já esta desenvolvido gostaria de dar algumas sugestões: - Manter o mesmo padrão dos nomes das propriedades do projeto da NFe, acredito que isso ajudaria bastante; - Falta a implementação da questão do Frete na Base de Calculo do Pis/Cofins, agora vem a questão na lei diz o seguinte para "Industrias ou Atacadistas", conversei com o Pessoal da Econet Editora, eles me passaram que poderia ser adicionado o Frete independente do ramo de atividade; -ST apenas é Calculado pela Alíquota do MVA, mas também temos a possibilidade de utilizar por PMC; Estou a disposição para ajudar a manter este projeto em funcionamento, caso tenha me passado em algo peço Desculpas, mas quem sabe com uma pequena explicação possa entender melhor a lógica do projeto.

Bom dia Italo, Sim ele faz parte da minha rotina.

Bom dia Italo, consegui resolver desta forma, antes de gerar o xml verifico o provedor e coloco a informação do MunicipioIncidencia em CodigoMunicipio, porque na versão 1.0 não tem o campo MunicipioIncidencia, pelo que analisei o provedor Betha trabalha nas duas versões (1.0 e 2.02) if (DM_NFSe.ACBrNFSe.Configuracoes.WebServices.Provedor in[proPronim,proBetha]) then Servico.CodigoMunicipio := IntToStr(Servico.MunicipioIncidencia);

Bom dia Italo Para não ter que criar um novo tópico, gostaria de ver com você a respeito do provedor Betha a versão 2.02 ele inclui alguns campos, percebi que nos fontes temos os seguintes métodos GerarServicoValores_V1 e GerarServicoValores_V2 na unit pnfsNFSeW, citei estes dois métodos pelo seguinte fato, um cliente meu esta tentando emitir uma nota para outro município esta dando erro porque não tem o campo MunicipioIncidencia, segue o site do provedor Betha: https://e-gov.betha.com.br/e-nota/login.faces, estou enviando em anexo os schemas e manuais para facilitar, fico no seu aguardo, para ver o que podemos fazer. Obrigado pela Atenção Betha.rar

Boa tarde Italo Vou tentar falar com o pessoal da Dueto, o único problema é que eles só atendem as prefeituras!

Bom dia Italo Pelo que deu para entender nos meus testes o provedor Pronim ao receber o xml compara o DigestValue gerado por nos, então quando é feito a assinatura do xml é feito com o "Id", mas depois é efetuado a troca para "id" e enviado para eles com o "id" ai acaba dando a rejeição: "E1 Assinatura do Hash não confere". Ai quando enviei para eles com o "Id" funcionou, acredito eu que tanto faz para eles ser "Id" ou "id", se manter o mesmo "ID" que tinha na hora que foi efetuada a assinatura do xml.

Boa tarde Italo Pensando bem da para nós mudarmos o arquivo ACBrNFSeUtil.pas nas funções AssinarMSXML e AssinarLibXML removendo o provedor proPronim da troca de "Id" maiúsculo para "id" minusculo, pelo fato que não é feito validação de lote então não teria problemas acredito eu, mas deixo para você escolher qual será a melhor opção. Obrigado pela Atenção!

Boa Tarde Italo Até que em fim consegui resolver o problema de Soledade - RS, no arquivo ACBrProvedorPronim.pas, tive que mudar o endereço do servidor e no arquivo ACBrNFSeNotasFiscais.pas tive que fazer uma alterar após a assinatura do xml, pelo fato que, quando é feito a assinatura a tag (InfRps Id) fica com o "Id" maiúsculo, mas na hora de salvar o xml é passado para "id" minusculo, ai ao enviar para o provedor ocorria a seguinte rejeição "E1 Assinatura do Hash não confere", ai para resolver este problema apos a assinatura eu efetuo a troca novamente para "Id" maiúsculo" antes de salvar o arquivo. Obs.: Pelo manual disponibilizado pelo pessoal do provedor diz o seguinte que a assinatura não é obrigatória, ai resolvi fazer os 2 teste com e sem assinatura, mas mesmo assim retorna a rejeição "E1 Assinatura do Hash não confere", então desta forma, passa a entender que a assinatura é obrigatória, também falei com um atendente do provedor e o mesmo me confirmou via e-mail que a assinatura não era obrigatória, ai vai entender. Segue em anexo os 2 arquivos e obrigado pela atenção! ACBrNFSeNotasFiscais.pas ACBrProvedorPronim.pas ACBrNFSeNotasFiscais.pas ACBrProvedorPronim.pas

Bom dia Italo A principio só tem o Ambiente de Produção para a cidade de Soledade-RS, alterei o arquivo ACBrProvedorPronim para o novo endereço, porém agora esta retornando a seguinte rejeição (E1 Assinatura do Hash nao confere), já entrei em contato com o pessoal da Prefeitura, passei o xml que estou enviando e o xml de retorno deles, para eles falarem com o pessoal da Dueto, nos tópicos a anteriores percebi que o pessoal conseguiu efetuar os envios com sucesso, acredito que tenha algo de errado com o servidor novo deles porque só alterei a linha 281 de: ConfigURL.ProRecepcaoLoteRPS := 'http://177.101.230.30/nfsews/services.svc'; Para: ConfigURL.ProRecepcaoLoteRPS := 'http://186.237.127.82/nfsews/services.svc'; Mas quando tiver um resultado positivo de envio, post os arquivos alterados. Obrigado pela Atenção!

Bom dia Italo Sobre a Cidade de Soledade acho que mudou o caminho da url do servidor deles de http://177.101.230.30/nfsews/services.svcpara http://186.237.127.82/nfsews/services.svc, não fiz o teste ainda, vou modificar e fazer um teste, se funcionar, post o arquivo aqui no fórum, pode ser?

Boa tarde Pessoal Estou com uma pequena dúvida em relação ao Número de Controle da FCI, no meu caso, tenho alguns clientes que devem repassar das notas de entradas (Compras) para as notas de Saídas (Vendas), este número ele pode ser variar? Por exemplo tenho o produto x, hoje vem um número e amanhã vem outro número, pode ocorrer isso? Obrigado pela Atenção.

Boa tarde Juliomar, obrigado pela Atenção, só não entendi direito, deve modificar alguma coisa ou esta correto assim mesmo os fontes, porque hoje por default esta gerando a informação do bloco k no arquivo!

Boa tarde EMBarbosa, para facilitar estou enviando uma imagem do erro que ocorre na hora de importar o arquivo no validador, e abaixo tem um exemplo de como está no arquivo gerar o bloco k: |H001|1| |H990|2| |K001|1| |K990|2| |9900|H001|1| |9900|H990|1| |9900|K001|1| |9900|K990|1| Uma Observação, quando remova as linhas referente ao bloco k e ajusto a quantidade de registro ai valida normalmente o arquivo... Obrigado pela Atenção!

Boa tarde EMBarbosa, não fiz os teste com o meu próprio gerador!

Boa tarde Juliomar Desculpa mas não poderia anexar o arquivo pelo fato que é de um cliente meu, mas o que tenho hoje é o seguinte: Publicada a versão 2.1.0 do PVA da EFD ICMS IPI. A versão anterior (2.0.34) poderá ser utilizada até 10/10/2014. Principais alterações: Inclusão do campo VL_ITEM_IR no registro H010 (a partir de 01/01/2015 - leiaute 009). Inclusão do bloco K (a partir de 01/01/2016 - leiaute 010) Publicada a versão 2.1.1 do PVA da EFD ICMS IPI. A versão anterior (2.1.0) poderá ser utilizada até 20/01/2015. Principais alterações: Inclusão do validação de código no registro 1400 conforme exigência de cada estado (registro 0200 ou tabela do estado). Registro 0200 - Alteração da obrigatoriedade do campo COD_ANT_ITEM que não poderá ser informado. Alteração no tipo do campo COD_LST para C, tamanho 5, no formato NN.NN. Registro 0220 - Obrigatoriedade deste regisgro quando o campo COD_ITEM do registro 0200 tiver sido utilizado no campo COD_ITEM_DEST do registro K220 e este tiver unidade diferente do COD_ITEM informado no campo COD_ITEM_ORI. Registro C370 - Inclusão de regra para verificação de numero sequencial de item. Registro D411 - Inclusão de regra para verificação do número do documento - NUM_DOC_CANC dentro do intervalo de cancelamento. Como mencionei a cima estou utilizando está ultima versão a 2.1.1, na hora de gerar o arquivo ela gera o Bloco k sem dados, porque não estou informando nada neste bloco, o único porem é que na hora de validar esta ocorrendo algumas rejeições, posso anexar a imagem caso seja necessário. Obrigado pela Atenção!

Bom dia Juliomar, hoje pela manhã modifiquei o layout do aquivo sped fiscal para a versão 009 e logo após gerei um novo arquivo e validei o mesmo no validador da versão 2.1.1, teoricamente a ultima versão que encontra-se disponível, porém ocorreram algumas rejeições por parte do validador, ele não aceitou o bloco k, só salientando não estou preenchendo o bloco k, ai fiz um teste tirando as linhas referente ao bloco k e validou normalmente, neste caso não seria de nós alterarmos a data para gerar o bloco k a partir de 01.01.2016 ou simplesmente a penas se a versão do layout for maior ou igual a 010?

Boa tarde Italo Atualizei meus Fontes do ACBR esta semana, e gerei uma versão para meus clientes, porém hoje um cliente meu tentou gerar uma NFSe e deu erro ao assinar o RPS, o provedor do mesmo é Pronim, percebi que houve uma Revisão de número 7941, que realiza a assinatura do provedor pronim. Hoje assino minhas notas pelo MSXML, onde ocorre a excessão é no método AssinarMSXML no seguinte código: signedKey := xmldsig.sign(dsigKey, $00000002); Saberia me dizer o que posso fazer para corrigir isso?? Obrigado pela Atenção

Boa tarde Isaque Corrigindo meu amigo Aluisio sobre a postagem dele, ele esta se referindo a unit ACBrEFDBloco_0_Class.pas método WriteRegistro0000, hoje temos os seguinte códigos: Check(funChecaCNPJ(CNPJ), '(0-0000) ENTIDADE: O CNPJ "%s" digitado é inválido!', [CNPJ]); Check(funChecaCPF(CPF), '(0-0000) ENTIDADE: O CPF "%s" digitado é inválido!', [CPF]); A pergunta que faço é os 2 campos são obrigatórios, ou informando apenas um já é válido?

Bom dia Amigos Pelo que estava olhando no manual da NFe, este CFOP que você esta utilizando exige que seja informada a tag do número do processo de drawback, outra coisa se vocês entende a questão do processo de utilização do drawback na exportação, ficaria muito grato se me explicassem porque tenho que implementar, mas não estou me achando muito, acredito que estas informações venham da compra... mas ficarei muito grato pela explicação.

Boa Noite Anderson A principio aqui no Rio Grande do Sul nós temos a emissão off-line da NFCe, então em até 24 hrs podemos transmitir a NFCe, como eu citei antes na hora de imprimir o Danfe era pego o qrCode do retorno da NFCe, porém não tínhamos retorno pelo fato de ser emitida off-line, com isso tínhamos um problema no qrCode (funcionava ao consultar, porém com uma exceção Digit Value incorreto). Depois da alteração ficou funcionando perfeitamente, porque agora pegamos o Digit Value da assinatura da nota, que vai ser o mesmo do Digit Value que retornará do sefaz. Uma observação a ser levantada, depois da assinada da nota não pode haver mudanças na estrutura do xml se não isso pode afetar o Digit Value, se você assinar ela novamente, certo que vai gerar um outro Digit Value, mas creio que isso não vai haver porque o Danfe já vai estar com o cliente consumidor, então depois disso, não deverá ter mais mudanças na estrutura do xml. Att. Rômulo Souza

Boa tarde Anderson, a principio foi resolvido, no Danfe da NFCe do quick report, pegamos o Digit Value, que é gerado ao assinar a nota, ao invés de pegar o de retorno que vai ser o mesmo do que foi gerado na assinatura. Portanto ai não da mais problemas com o qrCode ao consultar na sefaz a NFCe.

Boa tarde pessoal Minha duvida é a seguinte, quando referenciamos um Cupom Fiscal na NFe, colocamos o CFOP 5929 ou 6929 nos itens, como fica no caso de referenciar uma NFCe na NFe. Desde já obrigado pela Atenção! Pessoal Corrigindo minha postagem, encontrei o tópico a respeito do Assunto:

Bom dia Italo, segue em anexo os xml's do provedor Digifred. xmls.rar