rafikrafael

Boa tarde. Os problemas eram na própria receita, ontem mesmo já havia voltado a emissão de nf-e, e hoje voltou a de nfc-e.

Oi pelo que deu para entender a Sefa PR esta com algum problema nos certificados ou conexão segura, nf-e já esta ok, nfc-e ainda não. Vlw

Boa Tarde, Orlando conseguiu ver algo? Tbm estamos com alguns server2003 parados somente PR. Vlw

Bom dia, parece que tem um problema de rota entre GVT (VIVO) e a sefa SP, e valide sobre o java, a versão 91 não esta sendo recomendada pela sefa sp, atualize ela ou volte a versão. Verifique as configurações de certificado digital do ie também.

Boa Tarde. Tem alguma posição sobre a classe de boletos Sicoob Banco do Brasil. Obrigado.

Bom dia Inclua no arquivo ini de vcs o valor na guia geral Usecertificado. [Geral] UseCertificado=1

Então fiz uns testes com envio do difal todo zerado e ocorre erro na validação do schema no servidor da Sefa PR, a qual exige um % de alíquota interestadual, e se não envio o grupo ele reclama a falta. No meu entendimento e pelo que o pessoal da Receita PR me passou não devo gerar essa tag, porque não ocorre uma operação interestadual e sim uma operação dentro do estado. Vou seguir o que a nt 2015 003 1.60 valida, que é o estado de entrega, vou seguir essas validações. - Operação Interestadual (idDest=2) - Operação com Consumidor Final (indFinal=1) - Operação com Não Contribuinte (indIEDest=9) - Não é operação de prestação de serviços (não existe tag “ISSQN”). E indicador de presença = 1 gero o endereço de entrega como sendo o da filial emissora e não gero as informações de partilha.

Bom dia. Perante o que me foi informado pela sefa e pelo que a nt 2015 003 1.60 informa, somente deve ser calculado os valores se ocorrer a transferência de mercadoria entre os estados, o que não ocorre quando o cliente retira no balcão, sendo tributado totalmente no estado de origem.

Então confirmando sobre a DestDa pelo que verifiquei é a regra para todo o simples nacional pelo ajuste sinief, http://www.portaltributario.com.br/guia/destda.htm

Boa tarde. Aqui no Paraná, o campo vICMSUFRemet não deve ser = 0 para empresas simples nacional. Deve ser calculando como as empresas do regime normal, conforme o decreto e confirmação com a equipe da receita do pr. As empresas irão recolher a diferença para o Paraná por meio da DestDa. Agora estou na duvida sobre os estados já que esse é um decreto aqui do PR .

João da uma olhada no arquivo ini do provedor, no da betha em um teste retirei o ns3: de um dos atributos e ocorreu o erro, não validei o erro no código. Na betha foi essa parte que removi para testes, pois tinha pegado alguns exemplos da propria betha sem o ns3: e resolvi testar sem também =D. [Geral] VersaoSoap=1.1 Prefixo2= Prefixo3=ns3: -> tinha removido o ns3 e ocorreu o erro, voltei e ficou ok. Prefixo4= Identificador=Id QuebradeLinha=;

Boa tarde. Na versão do trunk2 na betha em homologação ainda esta ocorrendo o erro e45 cnpj não encontrado, já entrei em contato com a prefeitura para resolução e não sabem o que pode ser e não passam contato com a betha, e o forum deles não dão mais suporte. Fiz o teste em produção e o rps foi aceito e gerado a nfs-e, ainda tenho que fazer melhorias no sistema para ter os retornos corretos e outras, mas o envio funcionou =D.

Everton qual o erro que esta ocorrendo, por acaso é o "E45- CNPJ não encontrado na base de dados"?

Então Dercide essas mudanças já havia efetuado e ainda continua o problema aqui. E mesmo enviando com uma versão antiga, ocorre o mesmo problema. O seu aprovou o rps e gerou a nfs-e?

Então estou entrando em contato com o pessoal da prefeitura para verificar, porque mesmo usando uma versão antiga com trunk antigo esta com o mesmo problema em homologação e em produção esta enviando normalmente, com a versão do trunk antigo.