webjoel

Resolvido!

A partir de hoje (01/10/2015) a prefeitura municipal de São José-SC não funciona mais sob o serviço de nota fiscal eletrônica de serviços do provedor Pronim/GovBR e passa a funcionar somente sob os serviços do provedor Betha Sistemas. Esta mudança de provedor se estende desde o início do ano, mas a partir de hoje chegou-se a definição final e o provedor Pronim/GovBR deixou de funcionar (modo consulta somente), ficando somente o do Betha Sistemas, que é o oficial e único a partir de hoje para emitir notas. Fonte: http://www.saojose.sc.gov.br/index.php/sao-jose/nota-fiscal-de-servicos-eletronica-nfs-e Seguem as alterações para o trunk e trunk2. ACBr (trunk).rar ACBr (trunk2).rar

Bom dia, Realmente disponibilizei um código que não compilava, testei um e enviei outro arquivo. Desculpas. Segue codificação atualizada. Obs.: Esta versão já está funcionando nos nossos clientes. Obrigado. ACBr (trunk 2).rar ACBr (trunk).rar

Certo. Muito obrigado!

Boa tarde! Realmente haroldogb, você tem razão, assim como o próprio array com as descrições está com o tamanho incorreto. Segue em anexo as correções tanto para o trunk como para o trunk 2 para que seja disponibilizado oficialmente. ACBr (trunk 2).rar ACBr (trunk).rar

Concordo com você Juliomar, E este problemas dos provedores de NFS-e é complicado, principalmente porque cada cidade escolhe o seu provedor, assim não tendo um padrão e isso piora já que tudo é por licitação, então este tipo de troca as vezes pode ser bem comum, e seria conveniente que quem pedir uma alteração deste tipo, informe uma fonte e não um "disse que me disse". Tudo bem, neste caso, por enquanto os dois estão funcionando paralelamente, mas temos que seguir fontes oficiais. Eu olhei no site da prefeitura e também liguei pro setor de fiscalização, confirmei com dois servidores, o site está correto. Pra mim ficaria mais fácil que ficasse a Betha, pois nosso sistema já está homologado. Mas a Betha pode sair da prefeitura a qualquer momento, a GOVBR, só mediante a nova licitação e isso demora. Por isso peço ao colega Gamarra para verificar as fontes dele, para averiguarmos melhor isso.

Boa tarde, Coincidentemente também estou homologando o meu sistema em São José e a informação que eu tenho é outra, sendo que acabei de ligar para o setor de fiscalização da prefeitura, segue os fatos: Segundo o site da prefeitura (http://www.saojose.sc.gov.br/index.php/cidadao/servicos-cac-desc/emissaeo-de-notas-fiscais), tanto o provedor da Betha quanto da Pronim/GOVBR estão funcionando em paralelo, sendo que o sistema oficial é o da GovBR (desde dezembro de 2014), e que o sistema da Betha está funcionando como contrato emergencial, fator redundante, sendo que a qualquer momento o contrato pode ser encerrado, já o da GovBR é contrato de licitação, e não vai parar até que haja uma nova licitação, que não está programada. Este tipo de alteração deve ser feita com mais cautela, consultando fontes oficiais, e de oficial até agora é a do site que passei acima, onde diz que o sistema da Betha será desativado (em negrito).

Bom dia, Acho que deveríamos compartilhar aqui estas estruturas aqui no fórum, afim de discutirmos uma solução e implementar no acbr, segue a estrutura do provedor Betha: Na prática, dentro de Tag <Discriminacao>, deve-se proceder da seguinte forma: Serviço 1 1º Abrir Chaves { 2º Abrir Colchete Geral [ 3º Abrir Colchete (para o identificador) [ 4º Informar a descrição do identificador 5º Adicionar o sinal de igual após o identificador 6º Infomar o valor para o identificador 7º Fechar o colchetes do identificador 8º Repetir os passos 3,4,5,6,7 Para cada identificador, quantas vezes forem necessários 9º Fechar o colchetes (Geral) 10º Fechar Chaves Repetir os passo acima para mais de um serviço Vamos a um exemplo: <Discriminacao> {[[Descricao=Alug. Sist. Folha de Pagamento][Quantidade=3][ValorUnitario=1213.32][Deducoes=1.00][DescontoCondicionado=1.20][DescontoIncondicionado=1.12]] [[Descricao=Alug. Sist. RH][Quantidade=1][ValorUnitario=195.67]]} </Discriminacao>

Boa tarde, Estou homologando aqui na empresa o ACBr com Delphi XE 7, e como usamos aqui o Fortes Report, segue as considerações: 1 - No site oficial do Fortes Report existe apenas os fontes compilados até o Delphi XE3 (http://fortesreport.com.br/?page_id=25), logo para as versões mais novas do Delphi é necessário baixar o código fonte oficial, community edition (https://github.com/fortesinformatica/fortesreport-ce) e compilar de acordo com a versão utilizada; 2 - A versão Community Edition do Fortes Report gera as bpl com nomes diferente das implementadas no pacote de instalação do ACBrBoleto para o fortes (ACBr_BoletoFC_Fortes.dpk), no XE 7 por exemplo, ao invés de "RLibWinDXE7" é "FortesReportCE_Win32_DXE7_vcl"; 3 - Na versão Community Edition do Fortes Report não existe a função "SetVersion", chamada no fonte do ACBrBoleto para o fortes (ACBrBoletoFCFortesFr.pas), testando no XE 7, ignorando esta função o componente instala/compila e funciona normalmente. Segue em anexo, alteração para compatibilização deste componente. Favor analisarem e se for o caso, disponibilizar no SVN. ACBr.rar ACBr.rar

Boa tarde! Segue em anexo, alteração para compatibilização deste componente entre Delphi XE 7 e Rave Reports. Favor analisarem para disponibilizar no SVN. ACBr.rar

Certo, mas ainda não resolve o meu problema, haja vista, que no meu caso, o provedor não quebra a linha por meio de um caractere e sim por uma estrutura de tags criada pelo próprio provedor.

Claro, claro. Vou criar um tópico específico pra disponibilização SVN com a compatibilização.

Olá, Para esse componente não fiz, mas seria basicamente igual a este caso:

Boa tarde! Segue em anexo, alteração para compatibilização deste componente entre Delphi XE 7 e Rave Reports. Favor analisarem para disponibilizar no SVN. Obs.: Para os demais componentes do ACBr a alteração é a mesma. ACBr.rar ACBr.rar

Opa! Realmente era só isso mesmo. Funcionando 100% agora, mas será que se adicionar esta package não vai quebrar para as demais versões do Delphi?

Boa tarde, No meu caso o problema é com o Rave, eu já coloquei a diretiva para a versão do Rave: {$IFDEF VER220} Rave90VCL, {$ENDIF} // XE {$IFDEF VER230} Rave100VCL, {$ENDIF} // XE2 {$IFDEF VER280} Rave110VCL, {$ENDIF} // XE7 ACBrComum, ACBr_NFe2; e mesmo assim acontece o seguinte erro: Cannot load package 'ACBrNFeDanfeRVCodeBase.' It contains unit 'Datasnap.Midas', which is also contained in package 'dsnap210'. Do you want to attempt to load this package the next time a project is loaded?

Boa tarde! Segue em anexo, alteração para compatibilização do componente entre Delphi XE 7 e Quick Report. Favor analisarem para disponibilizar no SVN. Obs.: Para os demais componentes do ACBr a alteração é a mesma. ACBr.rar

Boa tarde pessoal! Passei pelo mesmo problema e a solução foi encontrada no fórum de dúvidas do provedor (Betrha Sistemas) que atende a maioria dos clientes da empresa onde trabalho, a solução pode ser vista neste link: http://forum.betha.com.br/phpbb/viewtopic.php?f=93&t=6939 Que resumidamente consiste em gerar no campo "Discriminação" uma espécie de estruitura JSON. Porém esta solução tive que fixar no nosso própria sistema, que até então tinha somente clientes atendidos pela Betha, porém agora surgirem clientes que utilizam outros provedores, onde alguns são simplesmente um caractere, outros, como no caso da Betha (web service v1, utilizado aqui no ACBr) é uma estrutura de dados. Com base nestas informações, gostaria de ler algumas sugestões em que parte do ACBr poderíamos implementar estas situações.

Bom dia Juliana, Tinha colocado como Resolvido este tópico sem testar, olhei o código fonte e compilei mentalmente, entretanto ao atualizar o componente e utilizar no meu sistema encontrei um problema, na função "GetOcorrenciasRemessa", linhas você deixou fixo no Result da array: for I:= 1 to 38 do begin Result[0].Tipo := TACBrTipoOcorrencia(I); Result[0].descricao := cACBrTipoOcorrenciaDecricao[i]; end; enquanto que o correto deveria ser: for I:= 1 to 38 do begin Result[i-1].Tipo := TACBrTipoOcorrencia(I); Result[i-1].descricao := cACBrTipoOcorrenciaDecricao[i]; end;

^^

Bom dia, Realmente a implementação estava gerando memory leak, uma stringlist resolveria somente parte do problema, ou seja, me traria em formato string, entretanto acho mais interessante que fosse retornando um objeto com o tipo e a descrição. Fiz uma nova implementação, segue em anexo para análise. ACBr.rar

Bom dia, Sim, concordo, mas você chegou a conferir a alteração que sugeri no anexo do primeiro post? Assim disponibilizando no código fonte do componente e assim disponível para todos? Assim não necessitando de ser implementando nas aplicações.

Bom dia Juliana, E a descrição da ocorrência? Isto me retornaria somente as constantes.

Boa tarde, Como não foi implementado o ajuste das margens no componente visual "ACBrNFSeDANFSeRV" para impresão da "DANFENFSE" estou disponibilizando a alteração que fiz diretamente no arquivo de layout do RAVE ("DANFENFSE.rav"), onde eu ajustei as margens superior, esquerda e direita para que na impressão as margens sejam impressas corretamente. Também corrigi alguns erros de português. Favor Administrador, validar e se assim for aprovado disponibilizar no fonte oficial para que todos tenham acesso a alteração. Estou a disposição. ACBr.rar ACBr.rar

Segue em anexo a alteração que fiz no fonte "ACBrBoleto.pas". Eu criei uma nova classe ("TACBrOcorrenciaRemessa"), a populei, e criei um método que retorna um array da mesma. Com isso tem como ser retornando pela função "GetOcorrenciasRemessa" as ocorrências disponíveis para remessa, com seu tipo e descrição. Favor Administrador, validar e disponibilizar no fonte oficial se assim for aprovado. Estou a disposição. ACBr.rar ACBr.rar