Rodrigo - Digibyte

Esqueçi, gerando no layout versão 1.1

Pessoal, estou anexando o que tenho do projeto. Estão sendo gerados os eventos iniciais e mais as duas primeiras tabelas. A situação é a seguinte: o programador que estava na empresa saiu (talvez dê continuidade como free) então não sei exatamente a situação do componente. Ele foi feito baseado no ACBRNfe, seguindo o mesmo padrão, gostaria de seguir esse caminho. Precisamos acertar as arestas, o ponto inicial para então darmos continuidade. Por favor, qualquer duvida me perguntem ou passem mensagem, inclusive se faltou alguma coisa .... AcbrEsocial.zip

Sim, completamos os eventos iniciais e atualizamos o layout. Me comprometo a colocar isso aqui até amanhã. Feito isso podemos ter um ponto de partida pra melhorarmos o componente. Rodrigo.

O que precisar é só ir perguntando ou me passando mensagem.

Estou aos poucos implementando o componente mas seria importante se desse um feedback sobre a usabilidade do mesmo, sugestões, etc

Segue mais uma atualização com novos registros, quanto as alterações que houveram em breve terá mais uma atualização.AcbrEsocial.zip

Já tenho vários outros registros prontos no ACBResocial, vou ver se até amanhã posto aqui.

Segue componente e exemplo de uso, lembrando que está em fase inicial Depois temos que organizar quem faz o que pra não repetir trabalho ACBr.rar

Vou disponibilizar os fontes ainda hoje, na verdade aproveitei parte de sua idéia mas implementando conforme é a nota fiscal eletrônica no acbr ...

Já enviei pro Isaque o componente AcbreSocial, é só questão dele disponibilizar, não sei quando vai fazer isso. Ele aproveita várias estruturas do nfe, sua estrutura de classes está definida e tem a parte de gerar o xml pronta. No momento está gerando rubricas e cargos e estou fazendo mais dois eventos (empresas e dados iniciais). O que precisa fazer: Seguindo o exemplo dos eventos que fiz fazer os outros (fácil mas chatinho); Implementar a parte de assinatura/transmissão lembrando que grande parte está pronta já que o acbresocial usa as classes/units da nfe e algumas outras ainda não estão definidas pela receita.

Certo, pode ser, de qualquer forma acho que o manual que está para ser lançado vai nos esclarecer melhor. Estou fazendo o componente TACBReSocial usando as units do acbr e seguindo o modelo da NFE. Está quase gerando o registro de de cargos (1030), até amanhã deve estar pronto já o componente instalável. Algumas coisas terão que ser alteradas e implementadas mas servirá de base para o resto, assim que estiver pronto aviso.

O que peguei do manual foi: Evento utilizado para inclusão, alteração e exclusã o de registros na tabela de RUBRICAS do empregador. As informações consolidadas desta tab ela são utilizadas para validação do evento de Remuneração dos trabalhadores. Para envio deste ev ento é necessário o envio prévio do evento de Informações Cadastrais do Contribuinte/Empregador Consequentemente se pode alterar e exluir creio que seja em um momento posterior aos dados iniciais, onde irão só as inclusões. Por exemplo, preenche o cadastro de eventos na carga inicial, dois meses depois é criada uma nova hora extra, manda o 1010 como inclusão desse evento.

Mas o S1010 - rubricas não vai fazer parte apenas dos eventos iniciais, se tiver alguma inclusão/alteração de rubrica ele deverá ser informado. Pelo menos foi isso que entendi. Então não sei se é conveniente herdar de TEventosIniciais Em relação ao ideEmpregador também pensei isso mas vi em algum lugar que a ideEmpregador tinha razão social e em outro não tinha (se não era ela era a de funcionário). Se achar no manual posto aqui.

Bom dia conversei com o Lucas e vou começar a ajudar a desenvolver o esocial, vou criar o componente ACBreSocial pra ver se conseguimos fazer o projeto andar, precisamos da colaboração de mais pessoas. Minha idéia inicial é usar o "esqueleto" do acbrnfe mas vou precisar de ajuda de quem já está mais ambientado com ele. Primeira pergunta: no nfe temos uma classe TNotasFiscais que logicamente implementa as notas fiscais. No eSocial existem vários arquivos, ex s1010(rubricas), s1020(lotações), s1030(cargos). Para seguir o padrão do nfe cada arquivo seria implementado em uma classe descendente de TACBrESocial assim como é TNotasFiscais de TAcbrNfe ? Por exemplo teríamos TAcbrESocial.Ts1010 , é correto isso ?

Assinar um outro xml qualquer (no cado do esocial), seria possível ?

Mas com o manual disponibilizado creio que já seria possível começar a montar o acbr esocial, eu posso ajudar bastante pois estou atualizado sobre o assunto, porém sinceramente, alguém com mais experiência no acbr teria que dar o ponta pé inicial.

Quais os primeiros passos, o que devemos fazer para dar inicio no projeto ?

Já utilizei o zebedee no passado, ele cumpre muito bem o que promete e dá uma grande diferença quando a questão é volume de dados. O maior problema do firebird na internet porém não é esse, é que ele fica comunicando entre o server e o client e isso tem um atraso muito grande. O zebede ataca um dos pontos, o volume de dados. Sua aplicação porém tem que trabalhar com o menor volume possível de dados trafegando e o menor número de consultas possível. Digamos, 10 consultas com "1Kb" de dados é muito mais lento do que uma com "20Kb", isso é acentuado no firebird.

É, não me expressei bem. Quero gerar um arquivo de crédito em conta corrente para pagamento de salário, nada a ver com cobrança. É utilizado o arquivo padrão cnab240 então pensei que talvez o acbr boleto possa gerar.

É possível usá-lo para gerar remessa de crédito em conta corrente ? Alguma dica ?

Pessoal, estou achando que as alterações efetuadas estão confusas, não documentadas, uma se sobrepondo a outra. Por exemplo, na unit ACBrEPCBLOCO_0_CLASS tem o seguinte trecho: with Reg0140.Registro0150.Items[intFor] do begin // Check(funChecaPAISIBGE(COD_PAIS), '(0-0150) %s-%s, o código do país "%s" digitado é inválido!', [COD_PART, NOME, COD_PAIS]); if Length(CNPJ) > 0 then Check(funChecaCNPJ(CNPJ), '(0-0150) %s-%s, o CNPJ "%s" digitado é inválido!', [COD_PART, NOME, CNPJ]); if Length(CPF) > 0 then Check(funChecaCPF(CPF), '(0-0150) %s-%s, o CPF "%s" digitado é inválido!', [COD_PART, NOME, CPF]); // Check(funChecaIE(IE, UF), '(0-0150) %s-%s, a Inscrição Estadual "%s" digitada é inválida!', [COD_PART, NOME, IE]); // Check(funChecaMUN(COD_MUN), '(0-0150) %s-%s, o código do município "%s" digitado é inválido!', [COD_PART, NOME, IntToStr(COD_MUN)]); Check(NOME <> '', '(0-0150) O nome do participante é obrigatório!'); Nele está comentado a função de checagem de município, coisa que não estava um tempo atrás. Não tem nada explicando o motivo, nem quem fez. Eu ia corrigir um erro que dava quando não era informado COD_MUN mas agora fico sem saber o que fazer.

Para o CST_PIS e CST_COFINS fiz uma alteração, e acho que já foi implementada no projeto, onde em vez de tipos é utilizado simplesmente string. Acho que dessa forma fica mais simples, não há necessidade de conversões, os dados podem ser aproveitados diretamente do banco de dados.

Alguma posição a respeito disso ?

O Isaque conseguiu "captar" extamente o que eu quiz dizer. Se decidirem mudar eu me proponho a fazer isso, é só avisar.

Boa tarde. Alguns dias atrás estava com uma dúvida em relação a utilização do acbr e foi respondida minha dúvida nesse link: viewtopic.php?f=12&t=2162 Hoje porém estou vendo que isto não é uma solução correta pra muitos casos. Por exemplo os campos CST_PIS e CST_COFINS não tem os códigos numerados a partir do zero em sequência (0, 1, 2, 3, etc) portanto se eu utilizar CST_COFINS := TAcbrSituacaoTribCofins(sp_c185.FieldByName('CST_COFINS').AsInteger) pra puxar o valor do baco de dados não vai funcionar. Quando o BD retornar "01" que é alíquota normal o acbr vai retornar "02" que é alíquota diferenciada. Perguntas: Por que criar um tipo específico (ex. TACBrSituacaoTribCOFINS) ao invés de simplesmente ler o valor que o banco de dados retorna? Não seria muito mais fácil? Qual a solução pra isso? Abrir cada classe a ser utilizada e fazer um "case" ou "if" gigante pra converter os valores em tipos do acbr? case CST_COFINS of stcofinsValorAliquotaNormal : strCST_COFINS := '01'; stcofinsValorAliquotaDiferenciada : strCST_COFINS := '02'; stcofinsQtdeAliquotaUnidade : strCST_COFINS := '03'; stcofinsMonofaticaAliquotaZero : strCST_COFINS := '04'; stcofinsValorAliquotaPorST : strCST_COFINS := '05'; stcofinsAliquotaZero : strCST_COFINS := '06'; stcofinsIsentaContribuicao : strCST_COFINS := '07'; stcofinsSemIncidenciaContribuicao : strCST_COFINS := '08'; stcofinsSuspensaoContribuicao : strCST_COFINS := '09'; stcofinsOutrasOperacoesSaida : strCST_COFINS := '49'; stcofinsOperCredExcRecTribMercInt : strCST_COFINS := '50'; stcofinsOperCredExcRecNaoTribMercInt : strCST_COFINS := '51'; stcofinsOperCredExcRecExportacao : strCST_COFINS := '52'; stcofinsOperCredRecTribNaoTribMercInt : strCST_COFINS := '53'; stcofinsOperCredRecTribMercIntEExportacao : strCST_COFINS := '54'; stcofinsOperCredRecNaoTribMercIntEExportacao : strCST_COFINS := '55'; stcofinsOperCredRecTribENaoTribMercIntEExportacao : strCST_COFINS := '56'; stcofinsCredPresAquiExcRecTribMercInt : strCST_COFINS := '60'; stcofinsCredPresAquiExcRecNaoTribMercInt : strCST_COFINS := '61'; stcofinsCredPresAquiExcExcRecExportacao : strCST_COFINS := '62'; stcofinsCredPresAquiRecTribNaoTribMercInt : strCST_COFINS := '63'; stcofinsCredPresAquiRecTribMercIntEExportacao : strCST_COFINS := '64'; stcofinsCredPresAquiRecNaoTribMercIntEExportacao : strCST_COFINS := '65'; stcofinsCredPresAquiRecTribENaoTribMercIntEExportacao : strCST_COFINS := '66'; stcofinsOutrasOperacoes_CredPresumido : strCST_COFINS := '67'; stcofinsOperAquiSemDirCredito : strCST_COFINS := '70'; stcofinsOperAquiComIsensao : strCST_COFINS := '71'; stcofinsOperAquiComSuspensao : strCST_COFINS := '72'; stcofinsOperAquiAliquotaZero : strCST_COFINS := '73'; stcofinsOperAqui_SemIncidenciaContribuicao : strCST_COFINS := '74'; stcofinsOperAquiPorST : strCST_COFINS := '75'; stcofinsOutrasOperacoesEntrada : strCST_COFINS := '98'; stcofinsOutrasOperacoes : strCST_COFINS := '99'; end;